In many circumstances, complementary hardware or software modules developed by different groups of individuals are required to interact with each other. To ensure that the interaction is successful, one or more of the groups define one or more interfaces where the interacting modules connect. One circumstance that benefits from implementing interacting modules is where a core software module interacts with a variety of domain specific interacting modules. The core module provides generic capabilities shared by all the domains, and the interacting modules provide domain specific details.
For example, a core module of a network management system may provide generic capabilities for managing a network, such as displaying the connections between devices, displaying the status of each device and enumerating the message traffic handled through each device. The network management system module interacts with device description modules that each describes the properties and actions performed by a particular device on the network, such as a particular router, hub, or bridge device. The software interface can be implemented in any of several ways known in the art, including sending messages to concurrently running processes or invoking routines in a library of routines, such as a library of routines loaded and linked dynamically at runtime, or some combination of these ways.
This arrangement of core and interacting modules provides greater flexibility than treating all applications in one module. Many changes in a domain or the development of new domains are accommodated by adding to the number of domain specific modules that can be interfaced to the core module. The core module need not be changed.
Another benefit of this arrangement is that the size or complexity of a single module, or both, is reduced. If the modules apply to one domain one at a time, a large number of domains can be accommodated in series by operating the core module with one applicable domain-specific module at one time. At any one time, the domain-specific properties of the non-applicable domain-specific modules are not included in the operational modules.
Another benefit of this arrangement is that more applications can be generated than could be generated with the resources of the developer of the core module alone. By publishing the interface, the domain specific modules can be developed by many different entities using their resources. This increases the number of applications using the core module.
However, problems begin to arise when the interface between the core module and the domain-specific interacting modules changes. FIG. 1A is a block diagram that illustrates this problem. Core module 102 represents an initial version of a core module with which one of several domain-specific interacting modules 112 may interact. The interface is represented by features 104, 106 of core module 102. The complementary interface is represented by features 114, 116 of interacting module 112a. Arrow 118 indicates that the interacting modules 112 are compatible with the core module 102, i.e., the interacting modules 112 have interfaces with complementary features that couple with the features of the interface of the core module 102.
When the core module changes its interface, for example, to provide improved functionality, a later version core module results. Later core module 132 has an interface having an additional feature 136. Interacting modules 142 designed for the new interface may include in the interface the additional complementary feature 146. Arrow 148 indicates that the interacting modules 142 are compatible with the later version core module 132. However, the interacting modules 142 designed for the later version core module 132 are now incompatible with the early version core module 102. The early version core module 102 does not have feature 136 and cannot interface with the complementary feature 146 on the interacting modules 142.
If the later version core module 132 is not designed to be backward compatible, the problem is even greater. The illustrated later version core module is backward compatible as shown. The later version core module has features 104, 106 that interface with all the features 114, 116, respectively, on the domain-specific modules 112 designed for the early version. Arrow 120 indicates that the interacting modules 112 are compatible with the later version core module 132. In some cases, the later version might not be backward compatible. For example, referring to FIG. 1B, a newest core module 162 that eliminates feature 106 would not be compatible with the earlier interacting modules 112, 142 that employ the complimentary feature 116.
With changing interfaces on the core module, not every interacting module is compatible with every core module, and users of the modules have to determine compatibility before using the modules together. One past approach for determining compatibility is to assign version numbers to the core module such that the version number increases in value with each successive version of the core module in time. For example, with reference to FIG. 1A, the early version core module 102 is given version number “2” and the later version core module is assigned version number “32.” When an interacting module is developed, it is assigned a version number equal to the version number of the core module at the time the interacting module is developed.
For example, domain specific interacting module 112a, designed after core module 102 and before core module 132, is assigned version number “2.” Similarly, domain specific interacting module 142a, designed after core module 132 and before any other core module, is assigned version number “32.” Then, before the modules are used together, compatibility is determined by comparing version numbers.
If the version number of the core module is less than the version number of the interacting module, the modules are incompatible and are not used together. For example, if the version number of the core module is “2” (such as for module 102) and the version number of the interacting module is “32” (such as for module 142a) the modules are incompatible and are not used together.
If the core modules are backward compatible, as shown in FIG. 1A, then the core module may have a version number greater than the version number of the interacting module and the modules would still be compatible. If the core modules are not backward compatible, then the versions numbers must be equal for the two modules to be compatible.
However, this past approach has numerous disadvantages. The past approach is manual, and therefore subject to human error. A developer of the interacting module may err in determining the current version number of the core module or in assigning the version to the interacting module. This problem becomes worse where the technology is relatively new, or commercial activity is involved in which rapid advances are important to maintaining market leadership. In these circumstances new versions of the core module are released frequently or before interfaces can be standardized by a comment and review process.
Furthermore the past approach often does not reflect the true compatibility between the interacting modules and the core module. For example, if interacting module 112b is developed after the later version core module 132 is released, then the past approach assigns a value of “32” to the version for the interacting module. However, according to the past approach, this version number indicates the interacting module 112b is not compatible with core module 102 having a version number of “2.” Yet interacting module 112b does not use the new feature 136 of the interface of the later version core module 132, and really is compatible with the early version core module 102. Thus assigning version numbers simply by the latest version of the core module when an interacting module is developed does not accurately reflect all the compatibilities.
An alternative approach is to set the version number of the interacting module to the earliest core module with which it is compatible. However, determining the earliest version using the past manual approach involves testing the module with several earlier versions until one is found that is not compatible, or involves examining all the features of the interface. This is a tedious process and subject to more human errors. The manual techniques are especially tedious and subject to error in software applications, where the interface can comprise dozens of routines and corresponding parameters of varying complex types.
Based on the foregoing, there is a clear need for techniques to automatically assign version numbers to interacting modules that correctly identify compatibilities with the earliest versions of a core module.